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REMARKS 

Claims 1 to 20 are pending in this application. Claim 15 was withdrawn. Claims 1-14 
and 16 have been rejected. Claims 1, 5, 9, and 14 have been amended. Claims 17 to 24 are 
new. In view of foregoing amendments and following remarks, the applicants request 
allowance of the application. 

Interview SummarY 

On April 22, 2009, Applicant's representative discussed patentably distinct features of 
the claimed invention over the cited art. For example, one feature Applicant's representative 
discussed was the authorization rules which identify form elements accessible to the user 
independent of any data in the form elements, which is a feature not disclosed by the cited art. 
Another undisclosed feature discussed was only giving authorization to those form elements to 
successive users that have not yet been edited. 

Claim Rejections under 35 U.S.C. S103 

Claims 1 to 8 and 16 are rejected as being unpatentable over R/es, in view of Phillips, 
further in view of Rivera, in view of Giljum, in view of Ramachandran. Claims 9-13 are rejected 
as being unpatentable over Menninger, in view of Ries, in view of Phillips, in view of Rivera, in 
view of Giljum, in view of Ramachandran. Claim 14 is rejected as being unpatentable over 
Menninger, in view of Ries, in view of Phillips, in view of Rivera, in view of Giljum, in view of 
Ramachandran, in view of Bray. Applicant requests withdrawal of the outstanding rejections 
because these references are not combinable in the manner suggested by the Examiner and do 
not teach or suggest all elements of the pending claims. 

Modifying /?/eff and Rivera Clianaes tlie Principle of Operation and Renders 
the Art Unsatisfactory 

Both Ries and Rivera disclose restricting access to certain objects and data by 
embedding security information in the object or data. This is contrary to the functionality of the 
claimed invention, which restricts access to form elements based rules in a lookup table 
separate from the objects, data, and form. 

Consider, for example, elements of claim 1 relating to authorization rules, which recites: 

the form elements indicating auttiorization for the user to develop the form 
element based on authorization rules independent of data in the form ... 
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authorization rules permitting the selection of form elements wherein the 
authorization rules include settings that I'dent/fy the subset of the form 
elements accessible to the user determined via a lookup table separate 
from the form; 



Also consider similar elements of claims 5, 9, 19, and 21, the elements of claim 9 which recite: 

retrieving a permission list from a lookup table separate from the form 

using an identifier associated with the user, the permission list identifying 
access rights for developing a plurality of form elements contained in the 
form, the form elements Including an element for global attributes of the 
electronic form including the layout of the electronic form; 

and the elements of claim 21 which recite: 

enabling access to the user for developing a subset of the form elements 
through a lookup table separate from the form where the lookup table 
contains the authorization rules associated with the user identification, the 
lookup table being configured to identify the subset of form elements 
accessible to the user independent of data in the form and the form 
elements. 



As far as these claims are concerned, the above mentioned elements of claims 1, 5, 9, 
19, and 21 refer to rules that allow a user to select specific form elements accessible to the user 
based on settings identifying form elements accessible to the user that are stored on a lookup 
table separate from the form. Neither the access control mechanisms in Ries nor Rivera can 
be modified to that of the claimed invention, because both of these references determine 
access to object by embedding access restriction elements within a document or form, and not 
in a lookup table separate of the form. 

Rivera, for example, discloses populating a digital form with data retrieved from a 
database, as discussed in the Abstract and H [7]. After populating the form, a user can then 
enter additional information into the form, which can then saved. Paragraph [59] of Rivera 
discusses how security controls can be implemented to ensure that only selected users may 
access specific data: 

In order to control access to information stored in a computer (according to the 
rules of the mandatory security policy) it must be possible to mark every 
object with a labelXhat reliably identifies the object's sensitivity level (e.g., 
classification), and/or the modes of access accorded those subjects who may 
potentially access the object. 



NYOl 1715951 vl 



-9- 



11884/400301 



Serial No. 10/665,258 

Response to Office Action mailed March 18, 2009 

Thus, R/Vera explicitly requires that each object, or in this case, each form element, be 
marked with a label identifying the sensitivity and modes of access. Because of these 
requirements, Rivera can not be modified to identify the subset of the form elements 
accessible to the user that is determined via a lookup table separate from the form, as required 
by the claimed invention. 5eeMPEP § 2143.01(VI) C'lf the proposed modification or 
combination of the prior art would change the principle of operation of the prior art invention 
being modified, then the teachings of the references are not sufficient to render the claims 
prima facie obvious."); MPEP § 2143.01(V). 

Similarly, Ries also discloses regulating access to data by embedding a label, or 'hook.' 
Ries discloses a method for editing web pages and identifying editable portions of a web pages 
by requiring 'hooks' to be Inserted in a web page, which may be achieved by adding HTML style 
comments within a web page, as discussed in [62]-[63]: 

In order for edit mode 222 to identif/ editable portions of a web page, editable 
portions 0^ a web page must be identified by a web page author through 
the use ofhooksand associated with a data source. [...] 
According to one embodiment of the invention, hook data may be embedded 
within HTML style comments provided as part of a web page. Generally, the 
syntax may be as follows: <l-VE:X:Y:Z->. According to this embodiment, the 
hook is preceded by an HTML start comment delimiter ("<!--"). This is followed 
by a hook type ("X") and a hook identifier ("Y"). [...] 

Once the 'hooks,' including a hook type, have been added to a web page, a web site 
administration can restrict access to the editing functionality by limiting access to data 
associated with hooks of a certain hook type, as discussed in H [73]: 

The web site or similar administrator must a/so set security detai/s to 
restrict access to the editing functionality the present invention vis-a-vis 
the web site, step 314. According to one embodiment of the invention, user data, 
including usernames and passwords, is maintained in appropriate data stores; 
each user has all or none access based on the presence of their username and 
password in the data stores maintained by the edit brain. Alternatively, it is 
advantageous to maintain security data by creating access groups whereby each 
group allows varying levels of access to advanced editing functionality provided 
by the invention. In this manner, the administrator is capable of restricting 
access with extremely fine granularity, e.g., allowing editing clients 
access to only certain hook tvoes that are enumerated in the security group 
to which the editing client belongs. 

Thus, Ries explicitly requires that editable portions of a web page subject to further 
access controls must be identified through the use of hooks embedded in the web page. Once 
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the hooks have been embedded, access In R/es can be restricted based on the hook type In a 
hook associated with an element In a web page. Because R/es determines access through 
hook types embedded In the web page or form and not through a lookup table separate from 
the form, R/es does not disclose Identifying form elements accessible to the user that are 
determined via a lookup table separate from the form," and/or ^^independent of data 
in the form " as required by the claimed invention. Furthermore, because Ries requires 
editable portions of a webpage to be identified through hooks contained in the web page, Ries 
can not be modified to eliminate and bypass the hooks to Identify form elements accessible to 
the user that are determined via a lookup table separate from the form, as required by the 
claimed Invention. See MPEP § 2143.01(VI) C'lf the proposed modification or combination of 
the prior art would change the principle of operation of the prior art Invention being modified, 
then the teachings of the references are not sufficient to render the claims prima facie 
obvious."); MPEP § 2143. 01(V) ("If proposed modification would render the prior art Invention 
being modified unsatisfactory for its intended purpose, then there Is no suggestion or 
motivation to make the proposed modification."). 

For all these reasons, the suggested modification of both Ries and Rivera Is Improper 
and Insufficient to render the claims obvious. Therefore, the rejections of claims 1, 5, 9, 19, 
and 21, should be withdrawn. Since claims 2 to 4, 16 to 18, and 23 depend on claim 1, claims 
6 to 8 and 24 depend on claim 5, claims 10 to 14 depend on claim 9, claim 20 depends on claim 
19, and claim 22 depends on claim 21, the rejection of these dependent claims should be 
withdrawn and/or the newly added claims should be allowed for the same reason. 

Bray does not teach "giving authorization to all electronic form elements to 
thg SMQQgssivg Msgr th^t h^vg ngt ygt bggn gditgd" 

Consider elements of claim 14, which recite: 

giving authorization to all electronic form elements to a first user of the 
electronic form; and 

for each successive user of the electronic form only giving authorization to those 
electronic form elements to the successive user that have not vet been 
edited . 

Also consider similar elements of claims 20, 22, 23, and 24. 

On page 10 of the March 18, 2009 Office Action, the Examiner asserts that ^^Bray 
teaches giving for each successive user of the electronic form authorization to electronic form 
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elements that have not been edited." However, Bray Is directed to locking elements In a data 
structure to allow multiple users to simultaneously edit unlocked portions of the data structure, 
as discussed In the Abstract, and not to giving access to unedited form elements to successive 
users of a form. 

Locks In computing applications are typically used to preserve data Integrity by 
preventing mutllple users from simultaneously changing the same data. Once a user Is done 
saving a data change, the lock Is typically released so that another user may later make further 
changes to the data. This Is precisely the locking scheme disclosed In Bra/at 4:55-5:3 and In 
Figure 3: 

Referring to FIG. 3, a typical sequence from a user's perspective illustrating the 
locking scheme follows. Suppose User #1 is viewing Requirement A and decides 
to add some more content. User #1 attempts to switch from the view mode to 
the edit mode on Requirement A. If no one else is editing or in some way 
modifying Requirement A, User #1 is switched to the edit mode. Meanwhile, 
User #2 is viewing Requirement A and decides to add some content as well. User 
#2 attempts to switch from the view mode to the edit mode. Since User #1 is 
already editing Requirement A, tliere is an existing locic ttiat prevents 
User #2 from switcliing to t/ie edit mode. User #2 Is notified of this 
situation and prevented from editing that Requirement A at that time. Once 
User #1 lias released the lock on Requirement A, User #2 may then 
edit Requirement A, unless User #1 actually deleted Requirement A. 

Thus, Bray discloses placing a temporary lock on data while the data Is being edited by 

one user; once the user Is finished editing the data, the lock Is removed so a second user has 

authorization to edit the data, even though the data has previously been edited by the first user. 

This Is different from the claimed Invention, which requires precisely the opposite, as recited In 

claim 14: "for each successive user of the electronic form giving authorization to all electronic 

form elements to the successive user that have not yet been edited." 

Therefore Bray does not disclose this element of claims 14, 20, 22, 23, and 24, and the 
rejection should be withdrawn and/or the newly added claims should be allowed. 

Ramachandran is not Analaaous Prior Art 

As discussed in the Title, Abstract, H [5] Background, and H [6] Summary, 
Ramachandran is directed to processes for licensing software on a usage basis, also known as a 
'pay as you go' software licensing, as recited in H [5]. The Examiner asserts that 
"Ramachandran teaches authorization rules include settings that Identify the accessibility to the 
user determined via lookup tables," and that it would have been obvious to combine the 
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teaching of Ramachandran with other cited art to block unauthorized accessibility. However, 
the claimed invention relates to restricting access to elements when constructing an electronic 
form, and it would not be obvious to consult a reference relating to 'pay as you go' software 
licensing processes. 

In order to rely on a reference in an obviousness analysis, the reference must be 
analogous prior art. See MPEP § 2141.01(a)(1). "[A] reference in a field different from that of 
applicant's endeavor may be reasonably pertinent if it is one which, because of the matter with 
which it deals, logically would have commended itself to an inventor's attention in considering 
his or her invention as a whole." See/d See also KSR Inti Co. v. Teleflex Inc., 550 U.S. 398 
(2007). In this case, considering references in the field of "pay-as-you-go" software licensing 
would not have logically commended itself to an inventor's attention since "pay-as-you-go" 
software licensing processes are not logically related to the claimed invention. 

Accordingly, the rejections of claims 1, 5, and 9, should be withdrawn. Since claims 2 
to 4, 16, and 23 depend on claim 1, claims 6 to 8 and 24 depend on claim 5, and claims 10 to 
14 depend on claim 9, the rejections of these dependent claims should be withdrawn and/or the 
newly added claims should be allowed for the same reason. 
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CONCLUSION 

All outstanding rejections have been overcome. It is respectfully submitted that, in view 
of the foregoing amendments and remarks, the application is in clear condition for allowance. 
Issuance of a Notice of Allowance is solicited. 

Although not believed necessary, the Office is hereby authorized to charge any fees 
required under 37 C.F.R. § 1.16 or § 1.17 or credit any overpayments to Deposit Account No. 
11-0600. 

The Office is invited to contact the undersigned at 212-908-6451 to discuss any matter 
regarding this application. 

Respectfully submitted, 
KENYON & KENYON LLP 

Date: April 23, 2009 By: /Ishak Akyuz/ 



Ishak Akyuz 
Registration No. 61,125 
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New York, NY 10004 
Tel.: (212) 425-7200 
Fax.: (212) 425-5288 
CUSTOMER NO. 53000 
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